Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/888

Internet Message Format | 1994-08-27 | 14.9 KB

Date: Tue, 19 Jul 1994 12:00:08 -0400 (EDT)
Date: Mon, 18 Jul 94 21:44 EST
Subject: Gem List (fwd)
Subject: Gem List (please post)
Subject:  Re: Gem List (fwd)
Subject:  Re: Gem List (corrected) (fwd)
Date: Tue, 19 Jul 1994 12:00:08 -0400 (EDT)
Mime-Version: 1.0
Precedence: bulk

Forwarded message:
>From [e-mail] Tue Jul 19 03:17:39 1994
Date: Mon, 18 Jul 94 21:44 EST
From: "Daniel J. Hollis" <[e-mail]>
To: ems <[e-mail]>
Subject: Gem List (please post)
Message-Id: <72940719024427/[e-mail]>

/yupload
Subject:  Re: Gem List (fwd)

Michael:
--------
> >My philosophy is that there should be *NO DISTINCTION ON BUTTON
> >FUNCTIONALITY* whether a window is in the 'background' or 'foreground'.
> >The *SAME BUTTONS* should work on the *SAME WINDOW* whether it's topped
> >or not.
> Get used to it; it is not going to change to match your philosophy.  The
> "top window" is an integral part of GEM.  It has been improved, so that
> you can operate window gadgets in the background, but the philosophy (if
> anything) has become more deeply ingrained.  The application receiving
> keystrokes is the one with the top window, the application that is
> active is the one with the top window, and so on.

I didn't make *any* mention about changing the keyboard focus. Why bring
that up at all since it wasn't even mentioned?

GEM is not going to change to match my philosophy; so we're writing a
GEM Library to *match* the philosophy. There is no reason why users have to
be stuck in the dark ages in terms of a user interface.

Maybe some people enjoy doing things the hard way, maybe you're one of
them? :-) However, some people actually have vision, and try to improve
on things rather than be content living in the past with a piss poor GUI
design.

> Here is an idea; why not try MausWind, and be happy.  It will
> automa[t]ically top the window as the mouse passes over it.  It is a very
> nice program, written by Thomas Binder.

That is exactly the kind of thing I hate, auto-window-topping. If you had
actually read my message, you would have realized that.

> >WinX also lets you 'pull' any window forward one level, or push it back
> >one level (or all the way to the back), without having to 'top' it first.
> >This is handy for rearranging the window stack without having to un-top the
> >application you're currently using.
> Sounds like a nice program; for the PC...  :)

It *IS* a nice program. We are implementing concepts from it into X-AES.

> >Should be a non-issue, IMHO. The same mouse buttons should have the exact
> >same effect on a window whether it's topped or not. Doing otherwise is
> >totally confusing.
> How is it confusing?  It has been that way from the start.  It isn't as
> if the behaviour suddenly changed and the user wasn't notified.

It's confusing in that it's a non-consistent GUI design. There is no reason
why programmers have to be content with atari's stupid mistakes.

> > >menu layout
> > This definitely needs discussion.
> What is wrong with the Atari standard menu layout?  It does not have
> any obviously stupid errors or such.

Other than the idiotic design in AES 4.x for hierarchical menus.

> >Have you actually TRIED this? Are you ASSUMING it will slow things down,
> >or are you speaking from experience having tried this? Try first, then
> >comment later. From experience, the speed difference is so incemantable,
> >that it's not even funny. ANYONE can LIVE with the speed difference:
> >There is none that you can see with the naked eye!
> Slower is slower; if you are going to go to the trouble of doing something,
> why not do it right?

We *did* do it right. If you had a copy of the demo program and used it, you
would never be able to tell that we do these so-called "time wasting" things,
unless we told you.

> >Face it, this is a *BIG* disadvantage.
> Perhaps, but your library will be just plain *BIG*.  I'd rather recompile,
> than waste memory on features I have no need for.

Wrong. Our library is much *smaller* than Gem++, yet has many more features.
The resulting executables that do the *same thing* as the equivalent Gem++
program are generally several times *smaller*, not to mention *faster*.

Go figure.

> >This is the *key* to background buttons, BTW. And it's *VERY* easy to
> >implement using this method.
> Well of course it is, but that does not mean it should be implemented.
> The 'topped window' is part of GEM, and the user will get confused if
> your program does not use it.  The only excuse for not using it is for
> a toolbar, or as a user-selectable option.

Maybe you'll become confused by a straighforward GUI design, but I think
you'll be just about the only one. :-) Changing the mouse button requirements
for selection of a topped dialog and a background dialog are totally against
a sane GUI design. But then again, nobody ever claimed atari is sane :-)

--Dan Hollis
----------
Subject:  Re: Gem List (corrected) (fwd)

Michael:
--------
> Please post from your own account, or sign-up the account you are posting
> from.  Would it really be that hard?

The account is shared, therefore it would be a bit difficult. :-)

> > Sounds like some of us enjoy re-inventing the wheel.
> Some of us do, if the wheel was brain-dead to begin with...  :)

Yet you criticize us for improving on the wheel. Where do you draw the line?

> >There. That was really difficult wasn't it? Now with the new window
> >installed, it WinLIB PRO handles the dialog, lets you move it, BACKGROUND
> >click buttons with the LEFT mouse button (and not some LAME left-right
> >button simultaneous click, I might add) and close it. WinLIB PRO handles
> >everything for you when you return a FALSE in the window dispatcher code.
> Is this really important?  Three lines of code, five lines of code, who
> really cares?

WinLIB PRO was designed after intensive study of over *20* GUI libraries.
It incorporates the best ideas of all of them (we steal from the best, and
forget the rest :-) WinLIB PRO is extremely powerful, yet extremely
easy to use. WinLIB PRO does most of the work for you, with an extremely
straightforward, simple API.

WinLIB PRO gives you the most amount of bang for the least amount of
effort (and code wise, WinLIB PRO is very, very efficient. Very very small
executables and very fast execution.)

> >From the consistent evasions of my questions, it's obvious you know
> >nothing about extended object types. (And yes, I fully expect you will
> >dodge this
> >statement with yet more doublespeak).
> Exactly what is it you want us to know about them (other than the fact that
> you have supperior knowledge of them).  I'll be the guine[a] pig, then.
> I know nothing of any importance about extended object types; I do not
> use them, and have no particular use for them.  Now what should I know?

Other than the fact that they are easily accessable from a resource
editor, and give a programmer much more control over the design of an
interface. It's possible to design complete hierarchical menu bars for
WinLIB PRO from a resource editor using extended object types, and never have
to write special code to support it (unlike AES 4.0 which requires you to
write special support code). Extended object types give you more control
over designing an application visually, rather than code wise. IMHO the
GUI should drive the application, not the application drive the GUI. Isn't it
the job of a GEM library to make programming easier, not more difficult?

>>> 1) They're afraid of GNU C/C++, since it's not a commercial product.
>>Wrong. I have no problems with using PD compilers. The reason I stay away
>>from Gnu C/C++ is that I don't have the resources to waste (i.e. tons of
>>RAM, and tons of diskspace). And the fact that Gnu C++ spits out binaries
>>roughly 5 to 20 times bigger than the *same code* in Pure C.
> This figure is... <censored>.  Try, on average, less than 50%-60% larger.
> There are other public domain compilers, like SozobonX, that produce
> good object code.

Sozobon produces good object code? *laughs* I think your standing with most
of the people in this conference has dropped about 20 points from that
comment alone. Sozobon code is mediocre to fair, but far from 'good'.

> >Background tasks are *meant* to be less responsive than the foreground
> >task. Otherwise there would be no distinction between the two. :-)
> What on earth are you talking about?  Wasted CPU time is wasted CPU
> time.  It has nothing to do with how responsive the background
> application is.  Wasted time affects performance, plain and simple.

I'm simply saying that the foreground application gets more 'attention'
than background tasks. No 'wasted' CPU time at all, just 're-allocated' CPU
time. After all, the application the user is currently interacting with will
be getting most of the mouse activity, don't you think? :-)

> >Better yet, break out a debugger and check things out for yourself. You DO
> >know how to use an assembler-level debugger do you not?
> Maybe he does, but I do not.  That would require assembly language
> programming skills, which not everyone has (or needs).

I think that if people in this conference spoke more from EXPERIENCE and less
from OPINION, we would be much more productive.

> >I've used MTOS enough to be disgusted with it. It's a piece of crap. Slow,
> >and inefficient.
> Slow, inefficient, STANDARD.  People use it, and like it.  They may all
> have fast machines, but they are still using it.

Very very few people I know are using MTOS. Most are disgusted with it like
I am. I know of *nobody* (except maybe you) who actually LIKES it. Even on a
Falcon030 it makes life miserable. On a TT it's barely tolerable.

> >Our multitasking design *requires* that we have a 0ms timer event, since
> >we allow multiple threads of execution within one GEM program, even without
> >MultiTOS. You are free to use slower timer events, but your subthread
> >performance will suffer.
> This sounds more complex tha[n] a dialog-library needs to be.  You mention
> that nobody uses GEM++, but will anyone use your library?  Not many people
> need threading, or the replaced AES functions that your library drags
> along with it.

Wrong. There is no reason why you *have* to use it. It's there if you want
to take advantage of it. If you don't use it, it doesn't get linked in to
your compiled code, therefore your claim that it 'drags along' stuff with
it is wrong. The interface for multithreading is extremely simple, btw.
The programmer has to do virtually NOTHING to support it. Multithreading
is handy when you need it though, and at least in WinLIB PRO it is
available.  If you're talking about C++, you're right; it DRAGS EVERYTHING
in your library along with it whether it's used or not...

We don't 'replace' AES functions BTW. We just modify the behavior of existing
AES functions. I.e. sliders become active sliders, you get access to new
special window types, hierarchical menus are a snap to design. Those
extensions are totally transparent to the programmer, (s)he never has to
think about programming special code to support it, since WinLIB PRO does
all the work for you (or none of the work, if that's your decision).

Consider the amount of people who use C++ over C on the atari, then re-think
the question about who will use the library.  I think you can answer that.

> > So, you're saying we NEED to watch for mouse rectangle events when our
> > application is not topped? That makes very little sense at all.
> Why does this not make sense to you?  This discussion started with
> an argument over changing the mouse shape when it passes over a
> specific object type.  Why should your program stop doing this
> just because it is not the top application?  If the mouse passes over
> one of the object types in your dialog (even untopped) it should
> change shape.  If you do something, do it right and do it completely.

If you can't enter text into a background window (the keyboard focus should
always be on the topped window), then why bother indicating editable
fields on a background window at all? Doing things the way you described
would be a poor GUI design.

> >Wrong. You do not "have" to do this. The slider in WinLIB PRO is defined
> >by its relation in the object tree to its parent object, and its extended
> >object type. There is *NO* reason whatsoever that you have to "attach" a
> >child object to its parent with some code to make it an active slider. In
> >a good library, this should be an inherent property from the structure of
> >the RSC file.
> Umm, this may sound like a stupid question, but what about if the contents
> of your active slider CHANGES.  If you start with three items in your
> resource file, but suddenly need to put fifty in the active scroller,
> will that not cause problems?  What if you start with fifty and
> suddenly decide you only need three?  Do you just let the memory being
> used by the list go to waste?  I much prefer having to link a list of
> text items to the slider, since that way I can grow/shrink the list
> whenever I feel like it.

You are confusing a slider bar with a listbox. Please try to distinguish
between the two.

It's not a problem because you should not be storing list items in the
dialog itself, but rather using the dialog as a 'window' to the list. You're
saying that a text editor should store the entire document in the resource
structure itself? That's silly. Besides, the size of the slider corresponds
to the number of units it can move.

(I could go into a discussion on memory fragmentation from alloc'ing and
 free'ing memory for dynamically growing and shrinking a listbox, but I
 digress...)

> >The point is that whereas in WinLIB PRO, these changes can be made with a
> >RSC editor, whereas in Gem++ it requires code changes and recompilation.
> If you change the resource structure, you will have to recompile your
> program no matter what, so this is not really a consideration unless
> the changes you are making are trivial (in which case you would not
> have to recompile no matter which library you use).

I never claimed otherwise. I just pointed out that to change from a normal
slider to an active slider in Gem++ required a code change and recompilation
whereas in WinLIB PRO it simply requires a change to the slider's extended
object type in the resource editor.

> >Why bother designing a GnuC++ based library when only a tiny fraction of
> >the programmers out there can use it? That seems to me like cutting your
> >own throat.
> Why bother designing WinLIB PRO and then insulting just about every
> programmer who would consider using it?  I cannot speak for Warwick,
> but I assume he wrote it because he wanted to use it, or he wanted
> to improve C++ for the Atari.

I'm not insulting every programmer who would consider using it. From the
very beginning, you have been against WinLIB PRO -- it sounds like you
would have not used WinLIB PRO anyways, so nothing lost.

(WinLIB PRO already has a following, btw.)

> [You know, your messages in this digest were all posted twice...]

It was posted once in the wrong format by accident.

--Dan Hollis
----------